ETSITS132 421 ve.s.o 



(2004-12) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

Telecommunication management; 

Subscriber and equipment trace; 

Trace concepts and requirements 

(3GPP TS 32.421 version 6.5.0 Release 6) 



JtSiP 




3GPP TS 32.421 version 6.5.0 Release 6 1 ETSI TS 132 421 V6.5.0 (2004-12) 



Reference 



DTS/TSGS-0532421 v650 
Keywords 



UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2004. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 32.421 version 6.5.0 Release 6 2 ETSI TS 132 421 V6.5.0 (2004-12) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 32.421 version 6.5.0 Release 6 3 ETSI TS 132 421 V6.5.0 (2004-12) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 4 

Introduction 4 

1 Scope 5 

2 References 5 

3 Definitions, symbols and abbreviations 6 

3.1 Definitions 6 

3.2 Abbreviations 8 

4 Trace concepts and high-level architecture 8 

4.1 Trace concepts 8 

4.2 Trace High Level Architecture 9 

5 Trace requirements 12 

5.1 General trace requirements 12 

5.2 Requirements for Trace data 12 

5.3 Requirements for Trace activation 13 

5.3.1 Requirements for Trace Session activation 13 

5.3.2 Requirements for starting a Trace Recording Session 14 

5.4 Requirements for Trace deactivation 14 

5.4.1 Requirements for Trace Session deactivation 14 

5.4.2 Requirements for stopping a Trace Recording Session 15 

5.5 Requirements for Trace Data reporting 15 

5.6 Use cases for Trace 16 

Annex A (informative): Trace use cases 17 

A.l Use case #1: multi-vendor MS validation 17 

A. 1.1 Description 17 

A. 1.2 Example of required data for this use case 17 

A.2 Use case #2: subscriber complaint 17 

A. 2.1 Description 17 

A. 2. 2 Example of required data for this use case 18 

A. 3 Use case #3: malfunctioning MS 18 

A. 3.1 Description 18 

A. 3. 2 Example of required data for this use case 18 

A.4 Use case #4: checking radio coverage 19 

A.4.1 Description 19 

A.4. 2 Example of required data to cover use case #4 19 

A.5 Use case #5: testing a new feature 19 

A.5.1 Description 19 

A.5. 2 Example of required data to cover use case #5 20 

A. 6 Use case #6: fine-tuning and optimisation of algorithms/procedures 20 

A.6.1 Description 20 

A.6.2 Example of required data to cover use case #6 20 

Annex B (informative): Change history 22 

History 23 



£75/ 



3GPP TS 32.421 version 6.5.0 Release 6 4 ETSI TS 132 421 V6.5.0 (2004-12) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication Management, as identified below: 

TS 32.421: "Subscriber and equipment trace: Trace concepts and requirements"; 

TS 32.422: "Subscriber and equipment trace: Trace control and configuration management"; 

TS 32.423: "Subscriber and equipment trace: Trace data definition and management"; 

Subscriber and MS Trace provide very detailed information at call level on one or more specific mobile(s). This data is 
an additional source of information to Performance Measurements and allows going further in monitoring and 
optimisation operations. 

Contrary to Performance Measurements, which are a permanent source of information. Trace is activated on user 
demand for a limited period of time for specific analysis purposes. 

Trace plays a major role in activities such as determination of the root cause of a malfunctioning mobile, advanced 
troubleshooting, optimisation of resource usage and quality, RF coverage control and capacity improvement, dropped 
call analysis. Core Network and UTRAN end-to-end UMTS procedure validation. 

The capability to log data on any interface at call level for a specific user (e.g. IMSI) or mobile type (e.g. IMEI or 
IMEISV) allows getting information which cannot be deduced from Performance Measurements such as perception of 
end-user QoS during his call (e.g. requested QoS vs. provided QoS), correlation between protocol messages and RF 
measurements, or interoperability with specific mobile vendors. 

Moreover, Performance Measurements provide values aggregated on an observation period. Subscriber and Equipment 
Trace give instantaneous values for a specific event (e.g. call, location update, etc.). 

If Performance Measurements are mandatory for daily operations, future network planning and primary trouble 
shooting. Subscriber and MS Trace is the easy way to go deeper into investigation and UMTS network optimisation. 

In order to produce this data. Subscriber and MS Trace are carried out in the NEs, which comprise the network. The 
data can then be transferred to an external system (e.g. an Operations System (OS) in TMN terminology, for further 
evaluation). 
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Scope 



The present document describes the requirements for the management of Trace and the reporting of Trace data across 
UMTS networks as it refers to subscriber tracing (tracing of IMSI or Private ID) and MS tracing (tracing of IMEI or 
IMEISV). It defines the administration of Trace Session activation/deactivation by the Element Manager (EM) or the 
network itself via signalling, the generation of Trace results in the Network Elements (NEs) and the transfer of these 
results to one or more Operations Systems, i.e. EM(s) and/or Network Manager(s) (NM(s)). 

The basic Subscriber and MS Trace concept that the present document is built upon is described in clause 4. The high 
level requirements for Trace data. Trace Session activation/deactivation and Trace reporting are defined in clause 5. 
Clause 5 also contains an overview of use cases for Trace (the use cases are described in Annex B). Annex A provides a 
high-level view of Trace functional architecture. Trace control and configuration management are described in 
3GPP TS 32.422 [2], and Trace data definition and management are described in 3GPP TS 32.423 [3]. 

In this release, the present document does not cover any Trace capability limitations within a NE (e.g. maximum 
number of simultaneous traced mobiles for a given NE) or any functionality related to these limitations (e.g. NE 
aborting a Trace Session due to resource limitations). 

The objectives of UMTS Trace specifications are: 

to provide the descriptions for a standard set of Trace data; 

to produce a common description of the management technique for Trace administration and result reporting; 
and 

to define a method for Trace results reporting across the management interfaces. 

The following is beyond the scope of the present document, and therefore the present document does not describe: 

tracing non-Subscriber or non-MS related events within a network element; 

tracing of all possible parties in a multi-party call (although multiple calls related to the IMSI specified in the 
Trace control and configuration parameters are Traceable); 

tracing of all active sessions in a cell or a given area (based on the identification of the area itself); 

tracing within an MS (the scope of Trace is only within the network). 

The definition of Trace data is intended to result in comparability of Trace data produced in a multi-vendor wireless 
UMTS network, for those Trace control and configuration parameters that can be standardised across all vendors' 
implementations. 

Vendor specific extensions to the Trace control and configuration parameters and Trace data are discussed in 
3GPP TS 32.422 [2] and 3GPP TS 32.423 [3]. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 
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[2] 3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace: Trace 

control and configuration management". 

[3] 3GPP TS 32.423: "Telecommunication management; Subscriber and equipment trace: Trace data 

definition and management" . 

[4] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 29.207: "Policy control over Go interface". 

[7] 3GPP TS 52.008: "Telecommunication management; GSM subscriber and equipment trace". 

[8] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

NOTE: Overall management principles are defined in 3GPP TS 32.101 [1]. 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Mobile Station (MS): term indicating Mobile Station and comparable to the terms Equipment and User Equipment 

management activation/deactivation: Trace Session is activated/deactivated in different NEs directly from the EM 
using the management interfaces of those NEs 

signalling based activation/deactivation: Trace Session is activated/deactivated in different NEs using the signalling 
interfaces between those elements so that the NEs may forward the activation/deactivation originating from the EM 

System Context: two different realisations of the telecommunication management architecture. System Context A has 
the Itf-N between a Network Manager and an Element Manger. System Context B has the Itf-N between a Network 
Manager and a Network Element that has an embedded Element Manager. See figure 1 in TS 32. 101 [1]. 

Trace: general term used for Subscriber and Equipment Trace 

Trace record: in the NE a Trace record is a set of Traceable data collected as determined by the Trace control and 
configuration parameters 

Trace Recording Session: time interval within a Trace Session while trace records are generated for the subscriber or 

MS being traced. 

The triggering events starting and stopping a Trace Recording Session are defined in 3GPP TS 32.422 [2] (figure 1). 

Trace Recording Session Reference: identifies a Trace Recording Session within a Trace Session (see figure 1) 
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Figure 1 : Trace Recording Session 

Trace Reference: identifies a Trace Session and is globally unique (see figure 2) 

Trace Session: time interval started with a Trace Session Activation and lasts until the Deactivation of that specific 
Trace Session (see figure 2) 

Activation Deactivation 

- IMSI or IMEI(SV) or Public ID - Trace Reference 

- Trace Reference 

- Trace control and configuration 
parameters 



1 



Time 



Trace Session 

Figure 2: Trace Session 

Trace Parameter Configuration: a technique whereby a request for tracing a certain subscriber or MS is sent by the 
EM to the Network Element for execution. 

Trace Parameter Propagation: a technique by which the NE processes the trace configuration (received from the EM 
or another NE) and sends it to the relevant Network Element(s) via signaling interface(s). 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [8] and 3GPP TS 32.101 [1] 
apply. 



Trace concepts and high-level architecture 



4.1 Trace concepts 



The diversity of Trace requirements makes it difficult to identify and anticipate all the operator's specific needs. Thus, 
the objective of this TS is not to list an exhaustive set of information to meet all the requirements. Rather, Trace data is 
defined without any limitation on the 2 following dimensions: 

Trace scope: NEs and signalling interfaces to Trace. 

Trace depth: level of details of Trace data. 

In order not to have any limitation of Trace data, there are three levels of details defined: Maximum, Minimum and 
Medium. The Maximum Level allows all Trace data to be recorded. The Minimum and Medium Levels provide a 
decoded subset of the data in the Maximum Level and allow an operator the flexibility in selecting the appropriate 
Trace data to record. 

The Trace Depth, specified at the Trace Session activation, is used to choose the level of detail of information to 
retrieve on the Itf-N. 

The Maximum Level of detail allows for retrieval of signalling interface messages within the Trace Scope in encoded 
format (see figure 4.1.1). 

Trace scope 

► 



Encoded 
messages 



Decoded 
lEs 



!■■■■■■ 



^ 



Maximum level of details: 
All messages are provided in 
their encoded format. 



Trace depth 



iLJz 



Specific set of lEs from encoded 
messages can be decoded by an 
external system. 



Figure 4.1.1 : Maximum Level of details of Trace 

The Minimum Level of detail allows for retrieval of a decoded subset of the lEs contained in the signalling interface 

messages (see figure 4.1.2). 
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^ 
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is provided to cover the 

most usual use cases. 



Trace depth 

Figure 4.1.2: Minimum Level of detail of Trace 

The Medium Level of detail allows for retrieval of the decoded subset of the lEs contained in the signalling interface 
messages in the Minimum Level plus a selected set of decoded radio measurement IBs. 

The Trace data recorded at each Level is defined in 3GPP TS 32.423 [3]. 

4.2 Trace High Level Architecture 

There are two types of activation, management based activation and signalling based activation. 

Figure 4.2.1 represents the high-level view of the architecture of Trace management based activation/deactivation. 
This figure is only showing the interfaces in principlea high-level view. Details of Trace activation/deactivation are 
defined in 3GPP TS 32.422 [2]. 
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Manager 




Network 
Element 



Figure 4.2.1 : Architecture for management based activation/deactivation 
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Figure 4.2.2 represents the high-level view of the architecture of signalling based activation/deactivation. This figure is 
only showing the interfaces in principle. Details of Trace activation/deactivation are defined in 3GPP TS 32.422 [2]. 
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Figure 4.2.2: Architecture for Signalling Based Activation/Deactivation 
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Figure 4.2.3 represents the high-level view of the architecture of Trace Reporting for System Context A. This figure is 
only showing the interfaces in principle. 
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Figure 4.2.3: Architecture for l-iigh-level view of Trace Reporting in System Context A 
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Figure 4.2.4 represents the high-level view of the architecture of Trace Reporting for System Context B. This figure is 
only showing the interfaces in principle. 
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Figure 4.2.4: Architecture for Trace Reporting in System Context B 



5 Trace requirements 

5.1 General trace requirements 

The general high-level requirements for Trace, common to both Management activation/deactivation and Signalling 
based activation/deactivation, are as follows: 

for the Maximum Level: Trace data encompassing all signalling messages on the different interfaces dedicated to 
the events of the traced subscriber or MS with their entire content (all IBs) shall be retrieved. The operator can 
then use an external system (e.g. an Operations System (OS) in TMN terminology) and decode specific 
information in line with operator requirements. 

for the Minimum Level: a selected subset of IBs shall be retrieved from the signalling interface messages. The 
Minimum Level provides support for the most common use cases (described in the annex B). 

for the Medium Level: a selected Minimum Level subset of IBs from the signalling interface messages and a 
selected set of radio measurement IBs shall be retrieved. 



5.2 Requirements for Trace data 



The high level requirements for Trace data, common to both Management activation/deactivation and Signalling based 
activation/deactivation, are as follows: 

The Trace records have to contain Information Elements or signalling messages from control signalling and/or 
the characteristics of the user data. The following list contains the Network Elements and the Traceable 
interfaces in the NBs where tracing is needed: 

- MSC Server: A, lu-CS, Mc and MAP (G, B, B, F) interfaces; 

MGW: ATM, IP and TDM interfaces for user plane characteristics; 
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HSS: MAP (C, D, Gc, Gr) and Cx interfaces and location and subscription information; 

- SGSN: Gb, lu-PS, Gn, MAP (Gr, Gd, Gf), CAP (Ge) and Gs interfaces; 
GGSN: Gn and Gi interfaces; 

- S-CSCF: Mw, Mg, Mr and Mi interfaces; 
P-CSCF: Gm and Go interfaces; 

- RNC: lu-CS, lu-PS, lur, lub and Uu interfaces. 

A unique ID within a Trace Session shall be generated for each Trace Recording Session. This is called the 
Trace Recording Session Reference. 

Changes to existing NEs and interfaces above may be required. These changes would be dependent upon various 3GPP 
working groups and possibly other non-3GPP industry groups for completion of Trace Session activation/deactivation. 

For a detailed description of network elements and interfaces above see 3GPP TS 23.002 [4]. 

5.3 Requirements for Trace activation 
5.3.1 Requirements for Trace Session activation 

The high level requirements for Trace Session activation, common to both Management activation and Signalling based 
activation), are as follows: 

In case of subscriber Trace, the Trace Session will be activated for a certain subscriber whose identification 
(IMSI in UTRAN/CS/PS) shall be known in the NEs where subscriber Trace is needed. 

In case of MS Trace, the Trace Session will be activated for a certain MS whose identification (IMEI or 
IMEISV) shall be known in the NEs where MS Trace is needed. 

Trace Session activation shall be possible for both home subscribers and visiting subscribers. 

There are two methods for Trace Session activation: Management activation and Signalling activation. 

For an established call/session within a Network Element, it is optional for the Network Element to start a Trace 
Recording Session for the associated Subscriber or MS upon receipt of the Trace activation request from the EM. 

A globally unique ID shall be generated for each Trace Session to identify the Trace Session. This is called the 
Trace Reference. 

Trace Session may be activated from the EM simultaneously to multiple NEs with the same Trace Reference 
(i.e. same Trace Session). 

The Trace Scope and Depth shall be specified within the control and configuration parameters during Trace 
Session activation. 

There can be cases in a NE when it receives multiple Trace Session activations for the same connection 
(e.g. simultaneous CS/PS connections). In these cases the starting time of the Trace Session Activation and the 
starting time of the first Trace Recording Session is the same using signalling based activation. For these cases 
there are two different cases for the Trace Session activation in a Network Element when it receives another 
Trace Session activation to the same subscriber or MS: 

If the Trace Reference is equal to an existing one, a new Trace Session shall not be started; 

If the Trace Reference is not equal to an existing one, a new Trace Session may be started. 

The EM shall always provide the trace control and configuration parameters to the appropriate NEs at the time of 
Trace Session activation. 
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The high-level requirements for Trace Session activation, specific to Management activation, are as follows: 

In case of subscriber Trace, the Trace Session will be activated for a certain subscriber whose identification 
(IMSI in UTRAN/CS/PS or Private ID in IMS) shall be known in the NEs where subscriber Trace is needed. 

5.3.2 Requirements for starting a Trace Recording Session 

The high level requirements for starting a Trace Recording Session, common to both Management activation and 
Signalling based activation), are as follows: 

It is optional for the NE to start a Trace Recording Session if there are insufficient resources available within the 

NE. 

The Trace Recording Session Reference shall be unique within a Trace Session. 

The Trace Recording Session should be started after appropriate start trigger events are detected. 

The high level requirements for starting a Trace Recording Session, specific to Management activation, are as follows: 

Each NE shall generate its own Trace Recording Session Reference (i.e., independent Trace Recording 
Sessions). 

Each NE shall start the Trace Recording Session based upon the Trace control and configuration parameters 
received by the NE in the Trace Session activation. 

The correlation of Trace data will be done with a Trace Reference and IMSI / IMEI / IMEIS V / Private ID. 

The Trace Recording Session can start only when the IMSI (in case of subscriber trace), the IMEI / IMEISV (in 
case of MS trace) or Private ID (in case of IMS) is made available in the NE. In order to trace the early phases of 
the call the IMSI (in case of subscriber trace), the IMEI / IMEISV (in case of MS trace) or Private ID (in case of 
IMS) shall be made available to the NE as soon as practically possible. E.g. the IMSI and IMEI / IMEISV shall 
be made available to both Serving RNC and Drift RNC. 

5.4 Requirements for Trace deactivation 
5.4.1 Requirements for Trace Session deactivation 

The high level requirements for Trace Session deactivation, common to both Management deactivation and Signalling 
based deactivation, are as follows: 

The Trace Session shall be deactivated using the Trace Reference specified for the Trace Session activation. 

The Trace Session shall be deactivated in all those NEs where it was activated. 

The deactivation of a Trace Session during a Trace Recording Session within a Network Element may take place 
anytime after the Network Element receives the deactivation request until the end of the current Trace Recording 
Session related to the traced Subscriber or MS. 

Trace Session deactivation in a NE could occur when two simultaneous signalling connections for a subscriber 
or MS exist. E.g. figure 5.4.1 shows NE 3 having two signalling connections (one of them or both of them are 
traced with the same Trace Reference) and a Trace deactivation message is received. The Trace Session shall be 
closed. 
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Figure 5.4.1 : Trace Session closure 

5.4.2 Requirements for stopping a Trace Recording Session 

The high level requirements for stopping a Trace Recording Session, common to both Management deactivation and 
Signalling based deactivation, are as follows: 

The Trace Recording Session should be stopped after appropriate stop trigger events are detected. 

Trace Session deactivation in a NE could occur when two simultaneous signalling connections for a subscriber 
or MS exist. E.g. figure 5.4.2 shows NE3 having two signalling connections, but only one connection is traced. If 
the non-traced connection is released, the Trace Recording Session shall be kept in NE3. If the traced connection 
is released the Trace Recording Session shall be closed. 



Traced 
connection 




Figure 5.4.2: Trace Recording Session closure 

The high level requirements for stopping a Trace Recording Session, specific to Signalling based deactivation, are as 
follows: 

The Trace Recording Session should be stopped after an NE receives the appropriate signalling deactivation 
message. 

5.5 Requirements for Trace Data reporting 

The high level requirements for Trace Data reporting, common to both Management activation/deactivation and 
Signalling based activation/deactivation, are as follows (Trace record contents, file formats and file transfer 
mechanisms are defined in 3GPP TS 32.423 [3]): 

Trace records should be generated in each NE where a Trace Session has been activated and a Trace Recording 
Session has been started. 

Format of the Trace records shall be XML Schema. 

Trace records should be transferred on the Itf-N to the Network Manager using one of two approaches: direct 
transfer from NE to NM or transfer from NE to NM via EM. 

For transfer of Trace records via Itf-N, FTP shall be used. 
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5.6 Use cases for Trace 

The operator can use subscriber and MS Trace for numerous purposes. However, the use cases for Trace can be divided 
into two basic categories: 

Troubleshooting use cases cover situations where the operator is solving an existing problem in his network; 

Validation testing use cases cover situations where the operator is not solving a known problem but merely 
analysing, fine-tuning or optimising his network. 

A more detailed description for the following use cases for subscriber and MS Trace can be found in annex B: 

Interoperability checking between MS from different vendors; 

QoS profile checking for a subscriber after a subscriber complaint; 

Malfunctioning MS; 

Checking radio coverage in a certain area; 

Testing new features; 

Fine-tuning and optimisation of algorithms or procedures. 
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Annex A (informative): 
Trace use cases 

A.1 Use case #1 : multi-vendor IVIS validation 
A. 1.1 Description 

The aim of this use case is to check how different vendor's MSs are working (e.g. in field testing) in the mobile network 
or to get detailed information on the MS. 

The study can be started by an initiative from operator for verification of MS from different vendors (e.g. testing how 
the MS fulfils the requirements set by the standards). 

The operator can perform the test using test MSs or tracing subscribers' mobiles. 

A.I .2 Example of required data for this use case 

The Trace parameters required to cover use case #1 are listed below; 

Tracing is needed in the Radio Network (RNC) or in the Core Network (MSS, SGSN); 

The identification of the Trace case shall be IMEI or IMEISV (and possibly IMSI); 

The level of details usually is to get the most important lEs from the signalling messages (Medium Level) or all 
messages with their encoded IBs (Maximum Level). 

The traceable protocols are: 

- In RNC: RRC, NBAP, RNSAP, RANAP. 

- In MSS/SGSN: DTAP messages. 

A.2 Use case #2: subscriber complaint 



A.2.1 Description 



The aim of this use case is to check how the complaining subscriber's services are working, to get information on the 
services in order to find out the reason for the complaint. 

The study can be started after a subscriber is complaining at his/her home or visited operator that some of the service to 
which he/she subscribed is not working. E.g. the subscriber: 

cannot make calls; 

cannot use some supplementary service; 

does not get the negotiated QoS level (e.g. Mobile subscriber activates video-streaming application to watch the 
latest sport events and every time the subscriber tries to connect to the service the system disconnects the 
subscriber's UMTS bearer). 

As the Trace is activated for a subscriber, the signalling based Trace Session activation shall be used, as the location of 
the subscriber is not known. 
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A.2.2 Example of required data for this use case 

The Trace parameters required to cover the use case #2 are hsted below: 

The Hst of NEs where tracing may be needed depends on the service being complained about by the subscriber. 
For this use case, tracing should be possible in all network elements, such as: HSS, MSS, RNC, MGW, SGSN, 
GGSN. 

The identification of the subscriber in a Trace is IMSI in UTRAN/CS/PS. The identification of the MS in a Trace 
is IMEI or IMEISV. 

The data includes those Information Elements from the signalling messages, which are related to the service(s) 
being complained about by the subscriber (Medium Level). 

Example cases, which can be the basis for subscriber complaint: 

1 . The subscriber's CS call is misrouted 

This illustrates an instance where a subscriber complains that his calls are being cross-connected (or 
misrouted). Such a complaint involves setting up a Trace at all the 3GPP standardised interfaces being 
handled by the MSC. However, the Trace functionality shall not cover MSC internal or vendor proprietary 
interfaces. The Trace record shall need to have the dialled number and connected number. 

2. The subscriber's call is dropped 

Tracing data is required from the radio network (UTRAN) or from the core network (MSS, SGSN, GGSN). 
In the radio network the radio coverage shall be checked. See use case #4 (checking radio coverage). Beside 
the radio coverage, other information can be useful as well, like RLC parameter, power information (OLPC 
or RRC measurement report), error ratios (BLER / BER, SDU error ratio), etc. Tracing in the core network is 
needed also, if the problem is not in the radio network. E.g. in case of PS domain the call can be dropped by 
the application due to the long delays or congestions in TCP layer or due to bad QoS. Thus in SGSN the 
requested and negotiated QoS parameters should be included in the Trace record. 

3. The received QoS level is less than the negotiated level. 

To be able to solve the possible problem Tracing data is required from HSS, SGSN, GGSN, and UTRAN. 
Furthermore in case of problem in CS calls tracing in MGW shall be performed. 

From HSS Trace data the operator can monitor whether the subscriber's authentication to the network is 
successful, and what kind of QoS parameters are allowed to the subscriber. From SGSN Trace data the 
operator can monitor PDP context creation request from mobile. Request seem to contain legal QoS profile 
(incl. Maximum bandwidth, guaranteed bandwidth etc) and the local resources in SGSN are available to 
provide the service as requested by the subscriber. From UTRAN Trace data the operator can monitor 
whether the maximum bandwidth and guaranteed bandwidth, requested by SGSN, acceptable for UTRAN. 
Thus to check whether UTRAN can provide and maintain the requested radio access bearer services. From 
GGSN Trace data the operator can monitor PDP context activation between SGSN and GGSN. If the 
problem is in the CS domain the MGW Trace can provide the QoS data. 



A.3 Use case #3: malfunctioning MS 
A.3.1 Description 

The aim of this use case is to check a MS, which is not working correctly. 

The study can be initiated by the operator when he/she suspects that a MS not working according to the specifications 
or he/she would like to get more information on a specific MS, which is on the grey or black EIR list. 

A.3. 2 Example of required data for this use case 

The Trace parameters required to cover the use case #3 are listed below: 
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- MS Tracing may be needed in the Radio Network (UTRAN) or in the Core Network (MSS, SGSN). 

The identification of the subscriber in a Trace is IMSI. The identification of the MS in a Trace is IMEI or 
IMEISV. 

The level of details depends on the operator needs (either Minimum Level or Medium Level). 

The malfunction of MS in UTRAN can occur in different places. The problem can be in basic RRC and RANAP 
signalling, Radio Bearer procedures, Handover procedures. Power control etc. 

Therefore, all RRC, RANAP, NBAP, RNS AP signalling procedures, transmission powers, error ratios (BLER / BER, 
SDU error ratio) and retransmission can be included in the Trace records. 



A.4 Use case #4: checking radio coverage 
A.4.1 Description 

This use case aims at checking the radio coverage on a particular network area. 

This study can be started by an initiative from operator for testing radio coverage on a particular geographical area 
following network extension for instance (e.g. new site installation). 

The operator can perform a drive test on the new site area, and check that radio coverage is correct. 

A.4. 2 Example of required data to cover use case #4 

The DL radio coverage can be checked using the values of CPICH Ec/No and RSCP measured by the mobile on the 
cells in the active set and the monitored set. These measurements are sent to the RNC trough the RRC message 
MEASUREMENT REPORT. 

The UTRAN Trace record intra frequency measurement contains the required information. 

The UTRAN Trace record inter frequency, and inter RAT measurements can also be used to check radio coverage with 
other frequencies or systems. 

After a network extension, the operator can check that Ec/No and RSCP levels on the new site area are the expected 
ones, and there is no coverage hole. 

The following Trace parameters are required to cover use case #4; 

- The type of NE to Trace is RNC. 

The identification of the subscriber in a Trace is IMSI. The identification of the MS in a Trace is IMEI or 
IMEISV. 

The Trace data to retrieve shall contain the messages with all lEs that are relevant for radio coverage. 



A.5 Use case #5: testing a new feature 



A. 5.1 Description 



This use case aims at testing the implementation of a new feature in the network before its general deployment. The 
functionality can be either a standard feature or a vendor/operator specific feature. 

This study is started by an initiative from the operator. 
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The operator can perform a drive test on the area where the feature is introduced, and check its good behaviour as well 
as its benefits, in term of quality or capacity. He can also rely on subscribers' Trace data when they use the feature to be 
tested. 

A. 5. 2 Example of required data to cover use case #5 

Depending on the feature, the list of NEs to Trace, as well as the level of details can be different. 

For a feature concerning Core and UTRAN networks, for instance hard handover, SRNS relocation, or new UMTS 
bearer service, the operator needs to activate Trace on several NEs. 

Then, the operator can be interested in: 

Only the protocol messages generated by the feature; or 

The impact of the new feature introduction on the network, for instance, the radio coverage, the capacity, the 
quality, or the behaviour of the existing algorithms. 

In this last case, the operator needs more detailed data, for instance messages with all (Maximum Level) or part of the 
lEs (Minimum Level). 

The following Trace parameters are required to cover use case #5: 

The types of NEs to Trace are NEs that can be traced related to the feature. 

The identification of the subscriber in a Trace is IMSI. The identification of the MS in a Trace is IMEI or 
IMEISV. 

The Trace data to retrieve can be either only the protocol messages (Maximum Level) or the messages with all or 
part of the lEs (Minimum Level). 



A.6 Use case #6: fine-tuning and optimisation of 
algorithms/procedures 



A.6.1 Description 



Subscriber and MS Trace is part of the optimisation process. Trace data are used to get feedback on the network quality 
and capacity after optimisation operations like parameter fine -tuning, or new network design. Each intervention to 
improve the network behaviour can be confirmed both by measurement data and Trace data. 

This study is started following an initiative from the operator. 

The operator can perform a drive test on the area where the optimisation has been performed, and check its good 
behaviour as well as its impact on the network. He can also rely on subscribers' Trace data when they use the feature to 
be optimised. 

A. 6. 2 Example of required data to cover use case #6 

Depending on the optimisation operation, the list of NEs to Trace, as well as the level of details can be different. But 
generally, fine-tuning activities like scrambling code plan, handover and relocation algorithms, or call admission 
algorithm optimisation concern a very specific part of the network. 

To cover this use case, the operator is usually searching for the highest level of details, on specific NEs. 

The following Trace parameters are required to cover use case #6: 

The types of NEs to Trace are any NE that can be traced related to the feature to optimise. 
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The identification of the subscriber in a Trace is IMSI. The identification of the MS in a Trace is IMEI or 
IMEISV. 

The Trace data to retrieve are the messages in encoded format with all (Maximum Level) or part of the lEs 
(Minimum Level). 
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